We'd be crossing a Rubicon by exposing support for a platform-specific IO primitive via JNI. I don't think we've done that before. I'd rather have a story for improved custom transport support, which I think would be more sustainable than threading through yet more special cases. docker-java implemented both UDS and named pipe transports via DetachedSocketFactory, and the main issue with that approach is that it requires the use of internal/experimental APIs; we would solve more problems by stabilizing that extension point, and offering a similar one in the async client (the java.io.Socket API is itself legacy).

If we were to implement this as a special case/first-class feature, I'd like to consider doing it on top of the Unix domain socket support. As far as I can tell, the named pipe support in docker-java is a legacy feature and an obsolete workaround for the lack of UDS support in Windows. It might be reasonable to add anyway, but it's not obvious that there's a lot of demand for it.

We'd be crossing a Rubicon by exposing support for a platform-specific IO primitive via JNI. I don't think we've done that before. I'd rather have a story for improved custom transport support, which I think would be more sustainable than threading through yet more special cases. docker-java implemented both UDS and named pipe transports via DetachedSocketFactory, and the main issue with that approach is that it requires the use of internal/experimental APIs; we would solve more problems by stabilizing that extension point, and offering a similar one in the async client (the java.io.Socket API is itself legacy).

If we were to implement this as a special case/first-class feature, I'd like to consider doing it on top of the Unix domain socket support. As far as I can tell, the named pipe support in docker-java is a legacy feature and an obsolete workaround for the lack of UDS support in Windows. It might be reasonable to add anyway, but it's not obvious that there's a lot of demand for it.

The real issue here is not named pipes per se, but whether HttpClient should grow another transport-specific request option.
I used Unix domain socket support as the closest existing precedent, but a generic transport extension point for both classic and async clients would be cleaner.

I am happy to rework the proposal in that direction if everyone is agree.